The present invention relates generally to computer devices, and more particularly to power management in compute-related devices.
ACPI (Advanced Configuration and Power Interface) is an open industry specification that defines a flexible and extensible interface for computer power management and related control operations. In general, the interface enables and supports power management through improved hardware and operating system coordination. ACPI allows the operating system to control the power states of many ACPI-compliant hardware components, and/or to pass information to and from some hardware components.
The ACPI Specification 1.0b describes how a system vendor can use General Purpose Events (GPE) to inform the operating system that a certain event has occurred. The specification distinguishes between run-time GPEs, which are related to events that occur while the computer is running, (e.g., state changes related to a thermal sensor or the power remaining in a battery), and wake GPEs, which are related to events that occur to possibly wake the computer system (or one or more devices therein) while the computer /device is in one of a plurality of sleep states. The specification allows the two types of events to be intermixed onto the same hardware signal.
ACPI enables individual devices of the computer system to go into a sleep state, thereby conserving power on the computer system. Device states may range from a D0 (working state) to D3 (fully off) state. The computer system as well may go into sleep-relative states, which may range from system state S0 (working) to S5 (fully off) with various possible states (e.g., S1, light sleep, S3 deep sleep, S4 hibernation) in between. Wakeup signaling events, such as the opening of a lid on a laptop computer, the pressing of a keyboard key, moving of a mouse, and so forth, are supposed to wake the devices and the system as necessary, such as to match a user""s preferences. More particularly, wake event signals are issued by a corresponding hardware device to a Status register pin, (e.g., a low signal is output to a formerly high signal register location, or vice versa). If the software is enabled for such an event, i.e., in a counterpart Enable register, some action (e.g., a system control interrupt or SCI) will be taken to wake a sleeping computer and/or a device associated with that register location. For example, one type of wake event that may result in a specific device being woken up is to wake up a modem (move the modem from the D3 to the D0 state, as well as wake the computer if necessary) when a telephone ring is detected.
While the ACPI specification thus provides directions for properly waking computer systems and the devices therein, a significant problem is that many system vendors connect certain wake GPEs in a way that violates the specification, thereby potentially confounding the operating system. Normally, when the operating system takes a GPE event, it begins by masking off the GPE Enable register for that event, processing the event, clearing the GPE Status register for that event, and then re-enabling that event in the Enable register. However, if the hardware is implemented incorrectly, the operating system is not able to clear the GPE Status register when it normally should, i.e., when the operating system performs its interrupt handling processing (to run a GPE method) and then attempts to clear the GPE Status register, the underlying hardware event is not dismissed by the hardware as it should be. Then, when the event is re-enabled in the Enable register, the event fires again. In other words, if a hardware signal cannot be cleared in accordance with the ACPI specification, the operating system thinks that the signal is cleared, whereby the signal is re-enabled and the operating system receives another notification that the event has fired and repeats the process. If the signal is still not cleared, then the operating system, which handles interrupts at a higher priority than other processing, is essentially stuck in an infinite loop handling interrupts (a general purpose event (GPE) storm) that cannot be terminated until the signal is clear. As a result, when the operating system tries to wake up from the sleep state, it cannot, because the GPE events will not clear, causing an interrupt storm. This may also occur while the device is in a running state, and an event signal corresponding to waking a device, such as a network card, cannot be cleared. Unfortunately for the owners of such machines, a vast number of machines are xe2x80x9cbrokenxe2x80x9d in precisely this manner, whereby their sleep features cannot be properly used. Further complicating matters is that certain hardware devices use GPE pins that share wake-up and run-time events.
Briefly, the present invention provides a method and system that solves the problem of interrupt storms by selectively enabling wake GPEs (in the Enable register) only when the operating system wants the particular devices associated with the wake GPEs to be able to notify the operating system that a wake event has occurred. The operating system thus intelligently manages wake GPEs. The operating system also distinguishes between events that are exclusively wake, run-time, and shared wake and run-time events. As part of handling the GPEs, the operating system may run control methods, and selectively re-run a control method when necessary to do so, such as if the execution of the control method failed, for example, because of a low memory condition.
To this end, in one implementation described herein, the present invention utilizes several algorithms to manipulate and remember various sets of state regarding GPEs. In this implementation, the sets of states are maintained in operating-system-internal structures referred to herein as software registers (a block of storage allocated in the computer""s main memory, having an arbitrary location, size and contents), including a GpeWakeHandler software register, which comprises a mask of bits representing GPEs used exclusively for wake-up events, a GpeSpecialHandler software register, which comprises a mask of bits representing GPEs which might be used for wake-up events but should be treated as regular GPEs, and a GpePending software register, which comprises a mask of bits which represent GPEs on which processing has started, but has not yet completed. A GpeRunMethod software register is also provided for tracking the running of the control method associated with each GPE, and a GpeComplete software register is provided to track completed events. In general, one difference between the GpeRunMethod software register and the GpePending software register is that GpeRunMethod software is only set until such a time as the ACPI driver is able to run the appropriate method. Once the ACPI driver is in a position to run the proper method, the GpeRunMethod software register is cleared. In comparison, the GpePending software register is set until the appropriate GPE method has successfully completed. The GpeRunMethod software register may be selectively reset to enable the same control method to be run again if needed, such as in the case of a failure.
The ACPI driver uses these masks in combination with a GpeEnable software register, GpeWakeEnable software register (which maintains a list of GPE pins which are enabled because of a wakeup event) and GpeCurEnable software register (which provides a mask of bits which are currently enabled) to intelligently manage the GPEs, and re-run control methods that fail to properly execute.
At boot time, the ACPI driver uses an algorithm to examine the system tables/namespace (built from firmware information) to determine which GPEs are associated with wake-up events, either exclusively or shared with run-time events, so that they can be managed differently from the other pins (which will be managed according to the ACPI specification). In particular, the ACPI driver looks for and specially handles the Lid, PowerButton, SleepButton, and Real-Time-Clock devices because these devices typically use a GPE pin that share wake-up and run-time events. Of course, other such mechanism may be similarly specially handled. Wake only events are enabled when the operating system deems it appropriate for them to be enabled, e.g., while the computer has been in a running state and the operating system has decided that some device needs that wake event enabled because the device needs to be able to wake up the computer.
In general, after the operating system has determined which GPEs are run-time, wake only, or shared, when the operating system receives events in the GPE Status register, the operating system runs an associated GPE control method. When the GPE method has completed, the operating system marks it as completed in a GpeComplete software register selectively determines whether the event needs to be re-enabled. This is done (in part) by determining if the event is wake only, (e.g., via access and manipulation of the state information in the registers), and if there is no outstanding request for that event to wake up the computer. If the GPE control method fails to execute properly, e.g., because of a low-memory condition, the GpeRunMethod software register is reset to re-run the control method as part of handling the GPE. The work item (e.g., deferred procedure call or DPC) that performs this handling may delay for a period of time, for example to give the system a chance to free memory.
A function is described that operates on the various registers to remove completed events from the list of those pending, remove events that are not in the current list of enabled events, remove each event for which there is a wake handler but which is not listed in the list of wake enables, and re-enabling those that remain. In that way, wake only events are enabled only when the operating system determines that they should be active, while shared wake and run-time events are enabled during run-time but handled differently. Control methods are also selectively re-run.
Other advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which: